Challenges and Preparedness of SDN-based Firewalls Vaibhav Hemant Dixit, Sukwha Kyung, Ziming Zhao, Adam Doupé, Yan Shoshitaishvili and Gail-Joon Ahn Arizona State University, Tempe, AZ, USA Email: {vdixit2, skyung1, zmzhao, doupe, yans, gahn1}@asu.edu ABSTRACT Software-Defned Network (SDN) is a novel architecture created to address the issues of traditional and vertically integrated networks. To increase cost-efectiveness and enable logical control, SDN provides high programmability and centralized view of the network through separation of network trafc delivery (the "data plane") from network confguration (the "control plane"). SDN controllers and related protocols are rapidly evolving to address the demands for scaling in complex enterprise networks. Because of the evolution of modern SDN technologies, production networks employing SDN are prone to several security vulnerabilities. The rate at which SDN frameworks are evolving continues to overtake attempts to address their security issues. According to our study, existing defense mechanisms, particularly SDN-based frewalls, face new and SDN-specifc challenges in successfully enforcing security policies in the underlying network. In this paper, we identify problems associated with SDN-based frewalls, such as ambiguous fow path calculations and poor scalability in large networks. We survey existing SDN-based frewall designs and their shortcomings in protecting a dynamically scaling network like a data center. We extend our study by evaluating one such SDNspecifc security solution called FlowGuard, and identifying new attack vectors and vulnerabilities. We also present corresponding threat detection techniques and respective mitigation strategies. ACM Reference Format: Vaibhav Hemant Dixit, Sukwha Kyung, Ziming Zhao, Adam Doupé, Yan Shoshitaishvili and Gail-Joon Ahn. 2018. Challenges and Preparedness of SDN-based Firewalls. In SDN-NFV Sec'18: 2018 ACM International Workshop on Security in Software Defned Networks Network Function Virtualization, March 19–21, 2018, Tempe, AZ, USA. ACM, New York, NY, USA, 6 pages. https://doi.org/10.1145/3180465.3180468 1 INTRODUCTION In traditional networks, both control and data planes are tightly integrated in physical devices. To specify routing policies in traditional networks, network administrators must maintain forwarding rules individually in all switches and routers in the network. In contrast, SDN has brought signifcant changes to how networks function by decoupling the control plane from data plane. The decoupling abstracts the higher level functionality and moves the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proft or commercial advantage and that copies bear this notice and the full citation on the frst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specifc permission and/or a fee. Request permissions from permissions@acm.org. SDN-NFV Sec'18, March 19–21, 2018, Tempe, AZ, USA © 2018 Association for Computing Machinery. ACM ISBN 978-1-4503-5635-0/18/03. . . $15.00 https://doi.org/10.1145/3180465.3180468 intelligence of network confguration to a centralized controller. This innovation has infuenced both industries and academic institutions to persistently work towards adaptation and evolution of SDN. The two main advantages of SDN (central programmability and visibility) tremendously improve cost-efectiveness and ease of maintenance in these complex networks. The security of conventional networks is often dependent on legacy frewalls and intrusion detection systems (IDS). However, both of these security mechanisms are ill-suited for protecting SDN environments. Traditional frewall functions are based on static rule set, which lacks fne granularity. Filtering the trafc is performed by matching every packet against allow or deny policies, using only source, destination IP addresses and TCP/UDP ports. Thus, the existing static and coarsely grained security mechanisms lack adaptivity and scalability. Consequently, it is critical that an SDN-based frewall solution leverages the functions of controller to enforce the security of SDN. Recently, there have been numerous studies to address security concerns that are specifc to SDN. Some of these work propose SDN-based frewalls that work in collaboration with controller and provide a centralized security framework [5, 7, 13]. However, the feasibility of these frewall solutions on enterprise networks is uncertain as these systems are often evaluated in simulated environments, such as mininet [2], which are inadequate to demonstrate their efciency in real world networks. Thus, it is critical to review current proposed SDN-based frewall solutions, discover the shortcomings, and identify ways to improve them for SDN deployment in real-world networks. In this paper, we revisit the existing SDN-based frewall designs to assess their readiness in protecting large-scale networks. We identify vulnerabilities in these existing designs for detecting security policy conficts in an SDN. Along with surveying shortcomings of the existing work, we also revamp one of the accepted frewall designs, called FlowGuard [7], as our case study. We identify shortcomings of the current FlowGuard design and propose improved measures for better performance and accurate confict resolution. We also observe that assessment of SDN security solution on a simulated environment does not guarantee its credibility in a real world network. Therefore, in our evaluation, we use an enterprise ready controller, OpenDayLight [3] and incorporate ScienceDMZ [6] network at Arizona State University, as the target underlying topology. 2 BACKGROUND 2.1 OpenFlow The decoupled control plane logic in SDN makes the forwarding decisions and enforces policies. This information sharing between SDN controller and switches takes place using APIs provisioned by OpenFlow protocol. OpenFlow enabled switches maintain the
Internet Firewall Control plane Data plane Figure 1: Firewall in a traditional network. fow routing policies in fow tables. A typical rule present in a fow-table has 3 diferent feld sets for packet handling: Match, Action and Statistics. The match set allows packet fltering based on header felds. After a successful match, the packet undergoes respective actions. As per the OpenFlow standard, the frst packet of a network fow is typically sent to the controller, which then inspects the packet headers and decides actions to be taken for rest of the fow. This action can be either to drop or forward. The central visibility in SDN is of great advantage as controller can extrapolate the future impact of trafc on any other node in the network. 2.2 SDN Controller In an SDN, a controller behaves much like a kernel of network operating system. Hardware based services of traditional networks like frewall and load balancer run as software applications within a controller. SDN-Controllers are capable of much more than a traditional control plane (in which a particular node remains oblivious of network activity on any other node in the network). Some light weighted controllers are used for academic testing and prototyping, whereas enterprise-ready ones are complicated in their design and functionality. Due to the lack of implementation standards, these controllers are implemented diferently and often leave security loopholes in their implementation and design. Two of the most popular SDN controllers on the market are OpenDayLight (ODL) and Open Network Operating System (ONOS). Both are open-source projects hosted by The Linux Foundation and difer greatly in their internal designs and implementation. 2.3 Firewalls A conventional frewall, as shown in Figure 1, is a system that protects trusted internal networks from the untrusted and unsecured outside world, such as the Internet. Firewalls flter and scan the trafc in and out of the network. In the SDN paradigm, the positioning, functionality and capabilities of a frewall assume multiple adaptations. Generally, they can be seen as an application running in the control plane, as shown in Figure 2. Security policies (such as Access Control Lists) for a network are defned centrally at the controller. The frewall converts these policies into fow rules which are installed in the network by a fow programming application. The placement of frewall logic on Internet Data plane Firewall Application SDN Controller (Control plane) Figure 2: Firewall in an SDN network. the control plane necessitates a novel design, tailored to protect SDN. Firewall with a centralized view of a network can functionally inspect local trafc to detect internal policy violations. Additionally, an SDN-based frewall can provide resolutions for the conficts at runtime. Unlike traditional frewalls, which flter and scan every packet coming and going through it, an SDN-based frewall analyzes the frst packet of each fow and installs rules for the rest of that fow in relevant switches. Moreover, since the network programmability is achieved from a software, multiple privileged sources (applications, users and administrator) can asynchronously install the routing rules and policies. Thus, SDN-based frewalls should implementconcurrent software listeners to get updates about policy and fow modifcations done on the network and verify the impact of such changes to prevent any violations. 3 POTENTIAL OF SDN-BASED FIREWALL As described in Section 2.3, an SDN-based frewall has a potential to be a holistic network security solution by leveraging centralization, high scalability and abstraction at the control plane. To harness these advanced capabilities, we identify seven vital features that a frewall should support to leverage the advanced network capabilities enabled by SDN. We then survey existing techniques in SDN-based frewalls to evaluate their readiness for securing an SDN network. (1) Centralized Policy Enforcement: The basic functionality of any frewall is to enforce security policies in a network. Thus, an SDN using traditional frewall hardware as a node in the network is not harnessing the advanced functions enabled by SDN: centralization and high programmability. Centrally-specifed policies can range from having fne granularity to being largely coarse. To enforce security on a network, the frewall converts these policies into fow rules which later get installed in the network. (2) Centralized Flow Tracking (end to end fow control): The rules installed in the network direct packets belonging to a particular fow from source to destination. Thus, any path taken by the packets belonging to a fow, can contain multiple fow rules from one or more switches. To efectively enforce the policy, SDN-based frewall keeps track of the fow path space. Merely confrming the policy on ingress and
Table 1: Comparison of SDN based Firewalls Firewall Controller Centralized Flow Tracking Centralized Confict Detection Multi-Tenant support Auto Priority handling Violation Resolution Concurrent updates Stateful Year Ethane1 [5] Ethane × ✓ × × × × × 2007 FortNOX [13] NOX × ✓ × ✓ × × × 2012 FlowGuard [7] FloodLight ✓ ✓ × × ✓ × × 2014 FW over SDN [15] POX × ✓ × × × × × 2014 SE-FloodLight2 [12] FloodLight × ✓ × ✓ ✓ × × 2015 AuthFlow [11] POX × ✓ × × × × × 2016 Reactive stateful FW [16] RYU × ✓ × × × × ✓ 2016 egress port of a switch cannot guarantee a successful confict detection, let alone resolution. Furthermore, building a fow path space by leveraging centralization guarantees to take into account the changes that OpenFlow allows in header felds of an in-route network fow. (3) Confict Resolution: Upon detecting a violation in the rules when a new policy or a fow rule is being added, a comprehensive frewall should provide a confict resolution too. Diferent instances, FlowGuard [7] and SE-Floodlight [12], prove that just allowing or denying a network update is not an efcient frewall design. If there exists a path in the network without a conficting entity, the frewall should dynamically perform resolution to give an updated path. Similarly, the new update may only partially cause a violation. In this case, the frewall should dissect the update into allowed/denied sets and process the allowed set. Therefore, a comprehensive SDN-based frewall must support dynamic confict resolutions. (4) Automatic Priority Handling: Diferent sources (for e.g., SDN controllers, applications, and administrator) update the security policies in a network. Assigning an authorization level to each source is important to prevent low priority updates from overriding crucial network policies. Moreover, an intelligent frewall should process these authorization issues automatically and provide a robust user experience. (5) Multi Tenant Support: A complex network, such as datacenters, can contain more than one sub-networks and multiple tenants for diferent services. Handling multiple tenants is not a special concern in a traditional networks as diferent frewalls are dedicated to each tenant network. However, in SDN, the controller has a centralized view of entire network topology and the frewall is responsible for centralizing the enforcement of security policies. SDN-based frewall should be capable of generating a distinction between subnetworks even if their address ranges overlap. (6) Scalability and Concurrency: In a dynamic and scalable network, updates of security policies are not always sequential. Multiple user threads or applications running inside an SDN controller make concurrent updates to modify frewall policy or fow policy. In case of conficting updates, lack of handling of concurrency could lead to low priority rules being handled before overlapping higher priority rules. The issue with concurrent updates becomes a problem when frewall applications are deployed in enterprise networks, where there are multiple pipelines which access and update the same confguration data stores. (7) Stateful Support: Maintaining the states of active connections gives a defnite advantage to the reliability of a frewall. Connection states can be obtained using information from OpenFlow communication. Information about the connection states should be formulated into time-bound fow rules for a network, providing fner granularity in frewall rules and a more accurate violation detection mechanism. 4 SURVEY OF SDN-BASED FIREWALLS Security in SDN has become a popular research topic these days. However, this focus arose almost a decade after the inception of Software Defned Networking. The very frst work on security of SDN [5] focused only on implementing access control lists within the SDN controller. Moreover, every work on SDN-based frewall focuses on certain aspect of SDN security but misses other important measures as shown in Table 1. Apart from the slow progress in SDN-security, there are other factors responsible for the absence of a comprehensive SDN-based frewall solution. First, there are no operation and design standards for SDN controllers. Since an SDN-based frewall is a software application running inside the controller, unless there exist norms for the design of an SDN controller, an agnostic SDN-based frewall is a distant dream. On the contrary, there exists a well maintained standard for the OpenFlow protocol [4]. It is intensely adapting to the new requirements. Signifcant changes in each of its revision demand correspondent changes in the frewall design as well. Finally, the existing SDN-based frewalls are developed and tested on simulated environments. Therefore, the efcacy of a frewall in an enterprise sized network often remains undetermined. Due to such factors, SDN-based frewalls become obsolete soon after they are proposed. The earliest SDN-based security solution, Ethane [5] accompanied the very pioneering work on SDN architecture. It showcased that security policies, instead of being defned individually on network entities, can be centrally enforced. No mitigation or threat prevention measures were discussed as the focus was on network programmability. With a lack of standard OpenFlow protocol, the policy enforcement was done only on a per-node basis via the 1ETHANE is a SDN architecture with inbuilt security 2Confict resolution is not done for policy violations on the network but between competing controller applications
controller. With increasing adaptation of SDN, security loopholes regularly surfaced, with various work focusing on attack detection and mitigation in SDN [14]. In FortNOX [13], security kernel has been proposed for the NOX controller. FortNOX frewall prevents unauthorized rule installations by assigning control plane applications and users to an authorization level. For a new policy, the decision to reject the update depends upon the installer's authorization level. FortNOX, however, is not a comprehensive frewall solution. It lacks accuracy, as the rule confict analysis is done in alias sets. The pairwise comparison ignores the rule dependencies and thus, provides an inaccurate result in complex networks with interdependent fow rules. It also lacks an ability to provide a fne-grained confict resolution. FortNOX is designed as an extension for the NOX controller, which is signifcantly diferent from enterprise controllers, and does not handle the challenges that arise when several sources race to install and modify rules concurrently. An SDN-based frewall FLOWGUARD [7] is proposed as a prototype solution built on FloodLight [1] controller. To detect fow policy violations, the frewall pulls network topology information from the data plane. It leverages NetPlumber [8] library to build a plumbing graph (logical snapshot of a network). Using a tracked space of a fow in the network comprising of initial source and fnal destination addresses, it centrally validates the security policies in entire network and provides dynamic resolutions. To demonstrate a software based frewall solution, a simple SDNbased frewall application [15] is proposed and deployed on the POX OpenFlow-based controller. This is an experimental project to prove the redundancy of hardware-based frewalls in an SDN network. Only the usability of the frewall is emphasized by providing a command-based user interface. Security-specifc features such as fow path space calculation and violation resolution are not given much importance. SE-FloodLight [12], an extension of FortNOX, is proposed as a security enforcement kernel for the FloodLight controller. SE-Floodlight provides resolutions to conficts that surface when multiple applications are deployed in the same network by pre-signing an application's class, which gets digitally verifed by frewall at runtime. However, trafc engineering (such as tracking the path of a fow to detect violations) is not done. Consequently, complex issues which arise due to indirect and partial conficts will go undetected. An access control mechanism based on authentication at layer-2 is proposed inAuthFlow [11]. To prevent the address spoofng and communication overhead, the security mechanism is placed in data link layer. The approach however conficts with the principle software-based model of SDN by employing decentralized security techniques. Realizing a need of an extra hardware (radius server) further increases the operational and confguration costs. A reactive SDN-based frewall [16] is proposed as a stateful solution. Policy enforcement is done based on the state of active connections in a network, mined in a local state table. Yet, the new generation requirements of the frewall (dynamic resolution and end to end fow path calculations) are not dealt with. Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport IP 5-Tuple Sense Figure 3: OpenFlow Ten-Tuple format 5 FIREWALL CASE STUDY: FLOWGUARD To discover the challenges faced by SDN-based frewalls, we deploy one of the existing solutions, FlowGuard, on a real and trafc-rich network topology (ScienceDMZ), which is managed by a production ready controller (OpenDayLight). We examine the number of SDN specifc features (centralization, scalibiltiy, abstraction and dynamic responsiveness) the existing solutions harness and select FlowGuard for an extended evaluation. Our decision of selecting FlowGuard as a representative study of the challenges faced by SDN-based frewalls is based on the quantifed scale (Table 1) on which we rate the existing solutions. First, to detect policy conficts, FlowGuard leverages centralization by taking into account the entire fow path space, unlike other solutions which inspect packet headers at ingress and egress ports only. Second, FlowGuard is relatively more agnostic in nature than other solutions as it uses open-source Header Space Analysis framework [9] to calculate rule interdependencies. In our experiments, we fnd multiple issues that FlowGuard faces when built on the latest infrastructure and tested on the actual complex network. These fndings, along with possible mitigation approaches, are discussed below: (1) Ambiguous Flow Path Space: We fnd that the IP-5 Tuple based approach used for confict detection (See Section 4) is prone to ambiguous fow path calculations. A frewall with a centralized view of two or more diferent tenant subnetworks cannot successfully distinguish one tenant from others based solely on IP 5-Tuples. In a tenant-based network (for e.g., in data center), multiple disconnected tenants use similar network confgurations. This leads to hosts having identical IP 5-tuple addresses in two disconnected sub-nets. On an OpenStack cloud with multiple diferent tenants, FlowGuard produces conficting fow path spaces which further leads to undesired resolutions. In order to prevent the confict, we propose to use a more fne-grained, OpenFlow 10-Tuple, as shown in Figure 3. Apart from the existing felds in an IP 5-tuple sense, an OpenFlow 10-tuple also includes a physical layer-2 port, protocol type, vlan id and ethernet type. With this fne-grained set of header felds, it is not possible to have duplicate route identifcation. In addition, we can also prevent the ambiguity in fow path space calculation. (2) Conficting Priority Handling: In a conventional frewall, priority of the rules are implicit based on their ordering. In
Match Action src=A, dst=B setfield={vlan=TAG} ,out=2 src=A, dst=B, vlan=C src=A, dst=B, vlan=TAG src=A, dst=B Match Action src=A,dst=B vlan=TAG Set-field= {vlan=" "}, out=3 Dependency broken using a unique tag The actual vlan value is lost - No match! Match Action src=A,dst=B vlan=C out=4 src=A, dst=B src=A, dst=B src=A, dst=B Match Action src=A,dst=B src=X,dst=B out=3 set-filed={dst=C},5 (a) Resolution method: Dependency Breaking using Flow-Tagging (b) Resolution method: Flow Rejection A C B src=X, dst=C Flow Match Action old src=A,dst=B out=2, setfield={src=X},2 new - - **DENY: A => B Violation!!
authorized communication that the wildcarded rule was previously allowing in the network. To prevent resolutions from losing availability of the network, higher-priority rules with fner granularity should be installed. The wildcarded fows require special attention as they are responsible for both allowed and denied trafc passing through them. Challenge 3. In the new OpenFlow protocol, actions per match in a fow rule can be chained. It means when a packet of a fow is matched by a fow rule in a switch, the same packet can undergo multiple relevant actions. Upon detecting a violation in a fow rule, deleting the entire fow rule deletes all the violating and non violating actions within it. Therefore, deletion of a fow rule requires careful examination. The action set within a rule can only partially violate the policy, just as entire fow rule can have partial violations. (4) Performance Issue: The response time of FlowGuard substantially increases as the network scales. This is because the confict detection algorithm is based on dynamically propagating a sample fow in the logical snapshot (plumbing graph) of a network. Such a graph can potentially have more than 100 nodes for a network of just 3 switches due to the fact that a node in a plumbing graph is a match and action set present in a fow rule. Various chained action sets in each fow, and several such fows, make for a complicated plumbing graph. When we tested the frewall on a convoluted topology of fow rules, the violation detection reached an order of seconds. This time is large enough for an unauthorized communication to take place before a confict is successfully resolved by a frewall. As an improvement, we propose to maintain a reachability map which is updated during the initialization process of a frewall. For future updates, full propagation of a sample packet from source to destination can be avoided. For this, we tested multiple hosts connected via 5 OpenFlow switches in a linear topology. When a new fow rule update for an intermediate switch in the fow path is made, a propagation check (for policy enforcement) from frst node to the last was ignored. Instead, with the information that 2/3 of the graph edges do not undergo a change, the propagation check happened only for the overlapping nodes in the graph. Thus, the performance is improved by reducing the propagation time in proportion to number of overlapping edges. (5) Disregard for concurrent updates: In our testing, we found issues when multiple threads make concurrent updates on frewall policy or fow policy. In case of conficting updates, lack of concurrency handling leads to low priority rules with a diferent action on same match being handled before the higher priority rule. For example, if an administrator installs a new fow rule in the network but a countermeasure engine (at the same time) installs a conficting action on the same match, the decision of the asynchronous frewall depends on which thread is executed frst. The confict detection and resolution algorithm should provide thread-safe security enforcement and take into account role-based access control. This can be achieved by using a privilege score assigned to each authorized application and user as an input to the algorithm resolving simultaneous action conficts. 6 CONCLUSION AND FUTURE WORK In this work we have juxtaposed existing SDN-based frewalls against each other to inspect their readiness to be deployed in enterprise and large scale networks. We have identifed various metrics that an SDN-based frewall solution should address. Seven diferent frewalls are then compared and evaluated against these metrics. As a case study, we have deployed FlowGuard [7] on ScienceDMZ network and discovered underlying vulnerabilities in protecting a large scale, complex network. The challenges are individually discussed and possible mitigation measures are proposed. With the advent of SDN, attacks can be fne-tuned to target diferent layers of SDN [10]. We want to extend the frewall to incorporate advanced features which protect the SDN network from various attacks targeting these layers. We plan to introduce an agnostic and comprehensive frewall solution of our own with such advanced capabilities to protect an SDN network from intrusions before their occurrence. ACKNOWLEDGMENTS This work was partially supported by grants from National Science Foundation (NSF-ACI-1642031) and a grant from the Center for Cybersecurity and Digital Forensics at Arizona State University. REFERENCES [1] Floodlight: SDN Controller. http://www.projectfoodlight.org [2] Mininet: An Instant Virtual Network on your Laptop (or other PC).